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Dynamic-Verification-Based Verification Apparatus Achieving High 
Verification Performance and Verification Efficiency and the Verification 

Methodology Using the Same 

[Field of the Invention and Description of the Related Art] 
<Field of the Invention > 

The present invention relates to a technique for verifying a digital circuit or a digital 
system, and more particularly, to a verification apparatus which is capable of verifying a 
digital circuit or a digital system using a verification apparatus for system integration 
circuit design, and a method using the same. Even more particularly, the present 
invention relates to the verification apparatus which can increase the verification 
performance and reduce the verification time, and a method using the same. 



<Description of the Related Art> 

The present invention relates to a technique for verifying a digital system having at 

least several million gates, and more specifically to a verification apparatus which 

increases the verification performance and efficiency when a digital system having at least 

several million gates is verified by simulation, and a method using the same. 

With the rapid development of integrated circuit design technology and 
semiconductor fabrication, the architecture of digital circuit designs has become very 
complex and the design complexity has grown to several million to several tens of 
millions of gates. The design having over hundred million gates is expected in the near 
future. However, as the competition in the market is getting more intense, the competitive 
products should be developed rapidly and the design verification takes up to 70% of total 
design time in recent chip design. Therefore, the need for efficient design verification 
method is growing to rapidly verify the designed circuits in automatic way \f the digital 
system is designed in a chip, the objects to be designed are two. One is DUV (Design 
Under Verification), and the other is test bench (abbreviated as TB thereafter). DUV is the 
design object that should be made eventually into chip(s) though the semiconductor 
fabrication process, and TB is the model of the environment where the corresponding 
chip(s) is mounted and operated. TB is used for the simulation of DUV. When DUV is 
verified by simulation, TB usually drives inputs to DUV and receives outputs from it. So 
far, to verify the digital circuits to be designed, Hardware Description Language 
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(abbreviated as HDL thereafter). System Description Language (abbreviated as SDL 
thereafter), or Hardware Verification Language (abbreviated as HVL thereafter) is used. 
In the early design phase, HDL simulators (for example. Verilog simulator, VHDL 
simulator. SystemVerilog simulator, etc), or SDL simulators (for example, SystemC 
5 simulator, HW/SW co-simulator, etc) are used, and in some cases even HVL simulators 
(for example. Vera simulator, e simulator, etc) are also used together with the simulators 
mentioned above. As all of them are software-based approaches and the simulator must 
execute the software code consisting of instruction sequence, which models the circuit to 
be verified and the test bench, sequentially on a computer, the degradation of simulation 

10 performance is inversely proportional to the size of design. For example, many 10 million- 
gate designs are running in either a HDL simulator or a SDL simulator on the computer 
having the fastest processor at the speed of 10-100 cycles/sec range at RTL, and 1-10 
cycles/sec range at gate level at most. However, as the total simulation cycles is needed 
in the range of a couple of million to a couple of billion to verify the design, the total 

15 simulation takes prohibitively long. There are some technologies that can reduce this 
long verification time. The first is to use a hardware-assisted verification system (such as 
simulation accelerator, hardware emulator. FPGA prototyping system, etc), and the 
second is to use a simulation farm which consist of multiple HDL simulators on one or 
more computers (for example, 100 units of workstations) in a high speed network. 

20 However, hardware-assisted verification systems cannot be used in the eariy design 
phase, their synthesis or compilation process takes much longer than that of HDL 
simulators, their use is much harder than HDL simulators, their purchasing and 
maintenance/repairing costs are large, and most of all, HDL simulators are much more 
favorable than hardware-assisted verification systems to either designers or verification 

25 engineers. Also, all hardware-assisted verification systems are used relatively in the 
restricted cases and to the limited number of customers because the original design 
codes, which are simulated by any of HDL simulators without any problems, cannot be 
executed in the systems. Increasing the performance of simulation by the use of 
simulation farms is possible only if there are at least two design codes or test benches. 

30 More over, even if there are more than one test benches, total simulation time is 
determined by the test bench responsible for the longest simulation time (for example, if 
the simulation time takes a week by a specific test bench, a week of simulation time 
cannot be reduced even with a simulation farm). This observation is also consistently true 
in the simulation with either SDL simulators or HVL simulators. Even worse, as the 

35 complexity of test bench is kept on increasing because there are varieties of components 
existing inside TB (for example, random stimulus generators, monitors, checkers, 
coverage tools, response checkers, etc), which is described in higher level of abstraction, 
the increased TB overhead is one of main components that constitute the slow down of 
simulation performance. The various test benches, or in some cases, some components 

40 in DUV are absolutely necessary in test bench automation, coverage-driven verification. 
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or assertion-driven verification for recent advanced verification technology, but their use 
results in the slow down of simulation significantly. Even worse, throughout using the 
advanced verification technology, only the existence of bugs in the design can be 
determined, or at best the possible buggy areas in the design can be known, but not 
5 possible to identify the exact location of bugs in the design. Intelligent human can be only 
responsible for identifying and eliminating the bugs in the design. To do this, the 
designers or verification engineers need to examine the signals or variables in DUV, and 
even in TB occasionally after probing them during the simulation. However, when these 
two situations exist together, the speed of simulation is degraded even more. 

10 Also, when TB is described in HVL, API(Application Program Interface) of HDL 

simulators, VPI/PLI/FLI, must be used in general, their use makes the simulation speed 
even slower More over, the most of designs starts at the register transfer level 
(abbreviated RTL afterward), and are synthesized into a net-list by some logic synthesis 
technology. At the other sides, to cope with the increased design complexity, there are 

15 some new attempts by starting the design by describing DUV and TB at higher level of 
abstraction such as behavioral level or system level, translating into a RTL automatically, 
and finally synthesizing into a net-list. But, their success is very unclear because most 
hardware designers opt to design at RTL, and the quality of design starting at more 
abstraction level is not good as much as one starting at RTL in terms of operation 

20 speed/area. Recent a couple of tens of million gate designs are usually SOCs which 
have one or more embedded processor. These SOCs also embeds significant software 
codes which drive those embedded processors. Therefore, in SOC design co-design and 
co-verification is absolutely needed to develop software together with the development of 
hardware concurrently. However. DUV described at RTL is too slow to be a platform for 

25 developing embedded software, but software developers need a platform on which their 
software can be executed fast enough for the development during the hardware design is 
under way. 

At present, the most widely used simulation is event-driven simulation. Besides, 
there are cycle-based simulation, and transaction simulation. In terms of abstraction level, 

30 event-driven technique is less abstract than cycle-based one, and cycle-based one is 
less abstract than transaction-based one. Cycle-based simulation is about 10-100 times 
faster than event-driven simulation, but imposes many constraints on the designs. 
Therefore, hardware designers are completely ignoring any cycle-based simulations and 
favorably using some event-driven simulations. Also, at present event-driven simulation, 

35 cycle-based simulation, and transaction-based simulation are used separately. Overall, 
these situations greatly hinder the verification with the high efficiency and performance. 



40 [SUMMARY OF THE INVENTION] 
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The purpose of the present invention is to provide a simulation-based design 
verification apparatus and a design verification method by using it for designing very 
large scaled digital systems. More specifically, the technology in the present invention is 
about the verification apparatus which uses simulation, and if necessary, formal 
5 verification, simulation acceleration, hardware emulation, and(or) prototyping (called a 
verification platform in a common name) together to increase the efficiency and 
performance of verification for verifying at least multi-million gate digital designs, and the 
verification method using the same. 

To debug design errors after simulation, the visibility on signals or variables in the 

10 design code is needed. But, the problem is it is impossible to predict which signals or 
variables are needed for the visibility before starting the execution of a verification 
platform. Therefore, it is usual that the simulation is run after choosing all signals and 
variables in the design code for probing as the candidates for dumping. But, dumping all 
signals and variables in the design code during the simulation easily slow down the 

15 simulation speed by factor of 2 to 10 times or even more than without dumping any 
signals or variables in the code. One of the objectives in the present invention is to 
provide an automatic method and a verification apparatus for it which can identify the 
locations of bugs in the design code while reducing the simulation time, compared to the 
traditional methods which require dumping all signals and variables in the design code at 

20 the beginning of simulation. Another objective in the present invention is to provide an 
automatic method and a verification apparatus for it which maintains the high visibility 
with the high performance when using test bench automation, coverage-driven 
verification, or assertion-based verification together with simulation in advanced 
verification. Still, another objective in the present invention is to provide an automatic 

25 method and a verification apparatus for it which keeps the high visibility for DUV, and 
simultaneously reduces the total simulation time greatly by using the simulation results of 
the higher abstraction level in the simulation at the lower abstraction level in the top-down 
design process. This eventually contributes to the efficient hardware verification, software 
verification, or hardware/software co-verification. Still, another objective in the present 

30 invention is to increase the overall verification performance and efficiency existed in the 
different level of abstractions by using the verification results of a higher level of design 
abstraction in the verification at a lower level of design abstraction through an automatic 
way, thereby accelerating the verification at the lower level of design abstraction, and if 
necessary increasing the verification efficiency at the lower level of design abstraction 

35 utilizing the verification results of the higher level of abstraction as a reference. Still, 
another objective in the present invention is to increase the overall verification 
performance and efficiency existed in the different level of abstractions by using the 
verification results of a higher level of design abstraction in the verification at a lower 
level of design abstraction through an automatic way, thereby accelerating the verification 

4 0 at the lower level of design abstraction, and if necessary increasing the verification 
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efficiency at the higher level of design abstraction utilizing the verification results of the 
lower level of abstraction as a reference. Still, another objective in the present invention 
is to increase the overall verification performance and efficiency by selectively using 
transaction-level simulation, cycle-based simulation, or(and) event-driven simulation in 
5 the optimal way in the process of the verification flow from top level of design abstraction 
to bottom-level of design abstraction, and using the verification results of a specific level 
of design abstraction in the verification at a different level of design abstraction. Still, 
another objective in the present invention is to increase the total verification performance 
and efficiency by using at least one or more of formal verification, simulation acceleration, 
10 hardware emulation, or prototyping together with simulation. 



[BRIEF DESCRIPTION OF THE DRAWINGS] 

The accompanying drawings, which are included to provide a further 
15 understanding of the invention and which constitute a part of this specification, illustrate 
embodiments of the invention and together with the description serve to explain the 
principles of the invention. 

In the drawings: 

20 FIG. 1 is an example of the schematic view of the design verification apparatus in 

accordance with the present invention; 

FIG. 2 is another example of the schematic view of the design verification 
apparatus in accordance with the present invention; 

FIG. 3 is a schematic view of a simulation process by the method proposed in the 
25 present invention; 

FIG. 4 is a schematic view of a bug finding and removing process throughout the 
simulation proposed in the present invention, which consists of the 1^^ simulation as the 
front-stage simulation and the post-1®* simulations as the back-stage simulation ; 

FIG. 5(a) is a schematic view showing a verification process in the verification 
30 using the apparatus showing in FIG. 1 or FIG. 2; 

FIG. 5(b) is a schematic view showing another verification process in the 
verification using the apparatus showing in FIG. 1 or FIG. 2; 

FIG. 6(a) is a schematic view showing a verification process in which the post-1®* 
simulations as the back-stage simulation are executed in parallel, using the verification 
35 apparatus in FIG. 2; 
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FIG. 6(b) is a schematic view showing another verification process, in which the 
post-1^* simulations as the back-stage simulation are executed in parallel, using the 
verification apparatus in FIG. 2; 

FIG. 6(c) is a schematic view showing another verification process, in which the 
5 post-1^* simulations as the back-stage simulation are executed in parallel, using the 
verification apparatus in FIG. 2; 

FIG. 6(d) is a schematic view showing another verification process, in which the 
post-1^* simulations as the back-stage simulation are executed in parallel, using the 
verification apparatus in FIG. 2; 

10 FIG. 7 is another example of the schematic view of the design verification 

apparatus in accordance with the present invention; 

FIG. 8 is an example of the schematic view of the design verification apparatus in 
accordance with the present invention which consists of verification software of the 
present invention, at least one computer having at least one simulator, and at least one 
15 hardware-assisted verification platform; 

FIG. 9 is an example of the schematic view of the design verification apparatus in 
accordance with the present invention which consists of verification software of the 
present invention, at least two computers having at least two simulators, at least one 
hardware-assisted verification platform, and a computer network which connects among 
20 them; 

FIG. 10 is an another example of the schematic view of the design verification 
apparatus in accordance with the present invention which consists of verification software 
of the present invention, at least one computer having at least one simulator, and at least 
one hardware-assisted verification platform; 

25 FIG. 11 is an example of the schematic view showing the reuse of the previous 

verification results in the verification using the apparatus in FIG. 8; 

FIG. 12 is an example of the schematic view showing the reuse of the previous 
simulation results in the verification using the apparatus in FIG. 1; 

FIG. 13 is an example of the schematic view showing the fast execution of 
30 verification process by re-using the verification results of any design objects unaltered 
on an arbitrary verification platform after some design objects are modified; 

FIG. 14 is an example of the schematic view showing the fast execution of 
verification process by re-using the verification results of any design objects unaltered 
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on an arbitrary hardware-assisted verification platform after some design objects are 
modified; 

FIG. 15 is an example of the schematic view showing the fast execution of 
simulation process by re-using the simulation results of any design objects unaltered 
5 on a simulator after some design objects are modified; 

<Explanation of symbols in figures> 

12: Test bench design object 14: DUV design object 

16: Design block design object 15: Input information for replay 

10 20: Design object modified 

22: Partial dynamic information collected before the design change 

27: Hardware-assisted verification platform 

28: A system software component in a prototyping system 

29: A system software component in a simulation accelerator 

15 30: A system software component in a hardware emulator 

31: The software module in the verification software which instruments either the 
additional code or the additional circuit to either a design code or a synthesized 
net-list in an automatic way 

32: Verification software 34: Simulator 

20 35: Computer 

36: A hardware component in a hardware emulator platform 

37: A hardware component in a simulation accelerator platform 

38: A hardware component in a prototyping system platform 

42: Model checker or property checker 
25 44: The software module in the verification software which is in charge of 

transferring files or data among more than one computers during the verification, 

executing the 1^* verification run, preparing the post-1°* verification runs, and 

executing the post-1^* verification runs. 



[DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT] 

To achieve the above mentioned objectives, the design verification apparatus of 
the present invention provides a verification software, one or more computer installed 
one or more verification platform (simulators, for example). The verification software is 
35 executed in a computer, and if there are more than one computer in a said design 
verification apparatus, those computers can transfer the files among them as they are 
connected in a computer network. Said one or more verification platform could be 
simulators, simulation accelerators, formal verification tools such as model checkers or 
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property checkers, hardware emulators, or prototyping systems, but from now on they 
are meant simulator otherwise specifically mentioned. 

If said one or more verification platform is(are) simulator(s), then they could be 
event-driven simulators, event-driven simulators and cycle-based simulators, cycle-based 
5 simulators, cycle-based simulators and transaction-based simulators, or event-driven 
simulators and cycle-based simulators and transaction-based simulators. The verification 
apparatus and verification method proposed in the present invention can be used both 
the gate-level verification using synthesized net-lists, the and timing verification using 
timing information back-annotated from the placement and routing to the gate-level net- 

10 list as well as the functional verification using original design codes. However, the 
detailed description is mainly focused on the functional verification because same 
techniques are easily applicable to gate-level verification or timing verification as well. 
Moreover, the functional verification can be done at RTL(Register Transfer Level), but 
also durable at behavioral-level or transaction-level which is even higher abstraction level 

15 than RTL. But, the detailed description is also assumed that the functional verification is 
at RTL mostly. Besides, the proposed method can be even applicable to the hybrid-level 
of verification which spans more than one design abstraction level. Said verification 
software instruments the additional code or circuit after reading the design codes in an 
automatic way. The instrumented code or circuit are basically additional HDL codes, SDL 

20 codes, HVL codes, C/C++ codes, simulation commands, or even more than one of those. 
During the simulation, they make possible to save either the simulation states or the 
states of design objects (to be explained later) which needs the visibility in DU and even 
the states of TB in some cases at the regular interval or more than one discrete 
simulation times, and later to start re-simulations from those saved simulation states or 

25 design objects states when the visibility is required. If the design states of one or more 
design objects in DUV, which requires the visibility, are saved but the states of TB are not 
saved, then the values on all of inputs and bi-directional input/outs in input mode are 
saved during the entire simulation period. The saving could be by every event, every 
cycle, or every transaction. A simulation state is represented by all dynamic and static 

30 information of a simulator at the specific simulation time during the execution of 
simulation. This is pretty similar to the state information of a program(process or thread) 
that makes possible the context switching between wait and resume in the multi- 
programming environment. A design state of a design object is represented by the values 
of all signals and variables in the design object. The design states of a design object can 

35 be classified into a complete design state or an incomplete design state, and minimal 
design state is a special case of incomplete design state. A complete design state of a 
design object is defined by the values of all signals and variables at a specific simulation 
time in the design object, and an incomplete design state of a design object is defined by 
the value(s) of at least one signal or variable at a specific simulation time in the design 

40 object. Also, a minimal design state in a design object is defined by the values of all 
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signals or variables in the design object which represent the outputs of storage elements 
(flipflops. latches, or memory cells), and if combinational feedback loops exist in the 
design object, any signals and variables on each loop. A TB state is defined by the 
values of all variables and signals in TB at a specific simulation time. When the 
5 simulation is resumed from either one of the saved simulation states, or one of the saved 
design states of design objects in DUV and in some cases one of the saved TB states 
together (if the design states of the design objects in DUV are saved but the TB states 
are not saved, then the simulation should be resumed from one of the saved design 
states of design objects in DUV with the values of all inputs and all bi-directional 

10 input/outs in input mode saved in every event, every cycle, or every transaction during 
the entire simulation period), the dumping on either all signals and variables or some 
specific signals or variables in the design codes can be carried out during the re- 
simulation. When using HDL simulators (for example, Verilog simulators, VHDL 
simulators or System Verilog simulators), an example of saving simulation states is to use 

15 a simulation system task, save (in case of NC- Verilog, Verilog-XL, or VCS) or checkpoint 
(in case of ModelSim) command, and an example of re-simulating with a specific 
simulation state is to use another simulation system task, restore (in case of NC-Verilog, 
Verilog-XL, or VCS) or restart (in case of ModelSim) command. Also, to re-simulate from 
a specific design state of one or more design objects previously saved as the initial state, 

20 the simulation should be started with said signals and variables in said design objects 
having said previously saved values. To do this, various methods in simulators, which 
provide controllability over the design, can be used. XMR(Cross Module Reference), 
force/release procedural statement, or some system tasks such as PLIA/PI/FLI are some 
of examples that can provide controllability. Therefore, the verification software in said 

25 verification apparatus of the present invention instruments the additional code or circuit to 
the original code, and these instrumented codes or circuits are responsible for doing 
these explained above in an automatic way. Such simulation technique can increase the 
performance and efficiency of the verification with following reason. As mentioned 
already, it is inevitable to probe some specific signals or variables in the design code at 

30 some specific period of simulation time to find and correct design errors. However, the 
problem lies in the fact that it is not possible to predict which specific signals or variables 
in the design are need to be probed at which specific period of simulation time prior to a 
simulation run. Therefore, it is possible to select some signals or variables to be probed 
only after a simulation is run at first and its result is evaluated. Then, while the 2"** 

35 simulation is executed from simulation time 0 until the time when the 1^* simulation is 
terminated, the dump on those selected signals or variables is carried out during a 
specific simulation period. But. the design error cannot be located at the 2"^ simulation, 
new signals or variables must be selected for probe and another simulation run needs to 
be executed from the simulation time 0 again. This process must be repeated many 

40 times until the location of the design bug is finally identified. This repeated many 
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simulation runs contribute very long overall verification time as every simulation run 
needs to start at the simulation time 0. To avoid these repeated simulations, the 1^* 
simulation run should be executed while dumping all signals and variables in the design 
code after selecting all of them to be probed before starting the simulation run. However, 
5 the simulation time could be easily increased by the factor of 2 to 10 times or even more 
if the dumping over all signals and variables in the design code is carried out in the 
simulation than the simulation time without dumping. Moreover, the data size of 
simulation waveform dumped during entire the simulation time for all signals and 
variables in the design code could be easily exceeded to couples of tens to hundreds of 

10 giga-bytes. To save this huge simulation waveform data, a very large capacity of hard 
disk is required and the bring-up time of this data, which has stored in a specific format 
(for example. VCD/extended-VCD in Verilog. FSDB from Novas, or simulator-vendor 
specific compressed file format such as SHMA/CD+) in a hard disk, to any waveform 
viewer takes a very long time. All of these also contribute the increase of total verification 

15 time. The simulation technique proposed in the present invention consists of a pair of 
simulation runs which are divided into front-stage simulation run and back-stage 
simulation runs. The front-stage simulation run is executed as fast as possible by not to 
dump all of signals and variables in the design code. But, during this 1^^ simulation run, 
the simulation states, or the design states of one or more design objects in DUV, which 

2 0 need the visibility, and if necessary the states of TB as well(if the design states of the 
design objects in DUV are saved but the TB states are not saved, then instead of saving 
TB states all inputs and all bi-directional input/outs in input mode are saved in every 

event, every cycle, or every transaction during the entire simulation period). SO. SI 

Sn, are saved at the regular interval (for example, every 100,000 nano-sec or every 

25 50,000 simulation cycles after the simulation run starts) or some specific simulation times 
to, t1, tn so that any post-1 simulation run can begin not from the simulation time 0 
but from a simulation time which is very close from the simulation time which users have 
a concern to watch. The saving of design states of design objects or values on 
inputs/outputs/inouts can be done by executing some dump commands (for example. 

30 some PLI system tasks such as $dumpvars, $dumports, etc). If the simulation states, or 
the design states of one or more design objects in DUV. which need the visibility, and if 
necessary the states of TB as well(if the design states of the design objects in DUV are 
saved but the TB states are not saved, then instead of saving TB states all inputs and all 
bi-directional input/outs in input mode are saved in every event, every cycle, or every 

35 transaction during the entire simulation period) are saved at one or more simulation times, 
any post-1^* re-simulation run can begin not only from the simulation time 0 but also from 

any simulation time of tO, t1, tn. Therefore, the debugging for a design can be done 

quickly and it could be a very efficient verification method as it can reduce the verification 
time greatly compared to the conventional simulation-based verification methods. We'll 

4 0 call this simulation method as Simulation-Method-A. 
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Anther method is to use the divide & conquer approach which utilizes the 
hierarchical structure existed in DUV or TB in a design code. In this case, the verification 
software Imports the design code and performs a partition on DUV and TB so that the 
design code is partitioned Into more than one design blocks (let's assume the design 
5 code is partitioned Into M design blocks), and selects all of Inputs and inouts of each 
partitioned design block as the candidates for probe, and Instruments the additional code 
or design which is responsible for the dumping the selected signals to be probed at the 
1^* simulation run, which is the front-stage simulation. Here, the design blocks include 
both DUV and TB also. Also, there are many sub-modules which are below DUV and TB 

10 in the hierarchy, and these sub-modules are also design blocks. We'll call any design 
block, DUV, TB, or even the combination of these as a design object. Therefore. DUT 
itself is a design object, so is each of sub-design blocks or even combined two or more 
sub-design blocks. After dumping the all of Inputs and inouts of each design block during 
the 1®* simulation run, which is the front-stage simulation, into a set of files, these dump 

15 data are converted into M TBs. and compiled with M design blocks to generate M 
simulation executable files by using the verification software in the present invention. 
We'll call this simulation method as Simulation-Method-B. In Simulation-Method-B, 
instead of producing VCD or FSDB, it is possible to produce one or more TB files directly 
using VPI/PLI/FLI during the 1^* simulation run. In this case, the translation process from 

20 VCD/FSDB into TB could be eliminated. 

Compared to the traditional simulation techniques, above two techniques can not 
only provide the high visibility on the design objects without scarifying the simulation 
speed severely, but also even increase the simulation speed greatly without using any 
hardware-assisted verification platform(for example, hardware emulator, or FPGA 

25 prototyping platform, etc) if the front-stage simulation and the back-stage simulation are 
executed at different levels of abstraction (will be explained more later). It is also possible 
to combine both SImulatlon-Method-A and Simulation-Method-B. However, both 
Simulatlon-Method-A and Simulation-Method-B can have following problems. For 
SImulation-Method-A, if the simulation period at a post-1 simulation run, which is back- 

30 stage simulation, (ts, te) is quite long, the simulation time could be also long as the total 
number of n+1 sequential simulation runs are required at ti, ti-1, ti-2, ti-n times 
although it could be less than the time required with conventional simulation. For 
Simulation-Method-B, if the number of design blocks to be simulated at a post-1®* 
simulation run, which Is back-stage simulation, (ts, te) is quite many, the simulation time 

35 could be also long as many sequential simulation runs are required although it could be 
less than the time required with conventional simulation. However. If simulators are two 
or more and the multiple computers, on which the simulators are executed, are 
connected in a network (for example, the X numbers of simulators are installed on the X 
numbers of computers), the post-1®* simulation runs, which is the back-stage simulation, 
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can be done in parallel. As these parallel simulation runs are completely independent 
with each other, any post-1^* simulation runs can be very fast. We'll call the parallel 
execution in Simulation-Method-A as the temporally parallel execution as it parallelizes 
the multiple executions in time, and the parallel execution in Simulation-Method-B as the 
5 spatially parallel execution as it parallelizes the multiple executions in space. 

Comparing the objectives of 1^^ simulation which is the front-stage simulation and 
post-1 simulation which is the back-stage simulation, it is known the post-1 simulation 
takes more time as it provides the visibility to DUV and in some cases TB as well, and 
the methods proposed in the present invention can reduce this greatly by using said 

10 temporal parallelism and spatial parallelism. However, to improve the total simulation 
performance further, it is also important to run the 1®^ simulation run, which is the front- 
stage simulation, as fast as possible while gathering the simulation result that contains 
the necessary information for one or more post-1^* simulation runs. There are many ways 
to achieve this. First method among them is to execute the 1^^ simulation run, which is the 

15 front-stage simulation, in parallel also on two or more computers. In this case, as each 
simulator cannot be run independently with each other, but co-executed together, it is 
very possible to have significant communication and synchronization overheads. Second 
method is to simulate with the new code which is translated for faster 1®^ simulation from 
the original code, and has same functionality as the original one but different syntax. The 

20 translation is basically to convert some syntax in the original code which takes long 
simulation time into a new functionally equivalent syntax which can be simulated faster. 
Eliminating some loop statements by un-rolling the loops, removing unnecessary lists in 
the sensitivity lists, eliminating the syntax related to delay constructs in some cases, 
having minimal procedural blocks by combining some of them in Verilog, having minimal 

25 processes by combining some of them in VHDL, changing some continuous assignments 
to procedural assignments and using different sensitivity list from the original for being 
evaluated less in Verilog, changing some concurrent assignments to processes and 
using different sensitivity list from the original for being evaluated less in VHDL, changing 
some continuous assignments to procedural assignments and using sensitivity list being 

30 evaluated less in Verilog, changing some concurrent assignments to processes and 
using sensitivity list from the original for being evaluated less in VHDL, adjusting the 
sensitivity list in the corresponding always blocks and processes for being evaluated less, 
and eliminating some signals or variables in the original code which are unnecessary for 
1^^ simulation are some of those examples. In this process, it is also possible to convert 

35 the design code into a structural description globally or partially, and temporarily or 
permanently using fast logic transformation or logic synthesis. Moreover, for the 
simulation efficiency it could be simulated after representing some parts of converted 
design in BDD{Binary Decision Diagram) or MDD{Multi-valued Decision Diagram). Third 
method is to simulate the 1^^ simulation run, which is the front-stage simulation, at the 
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high level of abstraction and the post-1 simulation runs, which are the back-stage 
simulation, at the low level of abstraction using the simulation results at the high level of 
abstraction. As the detailed examples, if an event-driven simulation is used at the post-1®* 
simulation runs, which are the back-stage simulation, then a cycle-based simulation 
5 which is 10 to 100 times faster than the event-driven simulation is used at the 1®* 
simulation run, which is the front-stage simulation. For the third method, the original 
design code written in either Verilog or VHDL can be converted into a SystemC code 
either manually or automatically (for example using HDL2SystemC translation tool), and 
a SystemC simulator is used. In general, as the event scheduler in the SystemC 

10 simulators is very right, it can be run faster than either Verilog or VHDL simulators. In 
case of second and third methods, while the 1^* simulation run which is the front-stage 
simulation is being carried out with either a SystemC simulator or a cycle-based simulator, 
the simulation states, or the design states of one or more design objects in DUV, which 
need the visibility, and if necessary the states of TB as well(if the design states of the 

15 design objects in DUV are saved but the TB states are not saved, then instead of saving 
TB states all inputs and all bi-directional input/outs in input mode are saved in every 
event, every cycle, or every transaction during the entire simulation period), are saved at 
the regular interval or some specific simulation times so that any post-1 simulation run 
can run in parallel with two or more HDL simulators on two or more computers. To do this, 

20 each sub-simulation in a run of one or more post-1 simulation runs is executed after 
initializing its initial state to a design state, which is saved at one or more simulation times 
at the 1®* simulation run that is the front-stage simulation. For TB for the post-1®* 
simulation run which is the back-stage simulation, same TB for the 1®* simulation run 
which is the front-stage simulation can be used. But also for the second and third 

25 methods, as it is not possible to use any simulation states as the different simulators are 
used for one for the 1®^ simulation run and the other for the post-1®* simulation runs, all 
inputs and all bi-directional input/outs in input mode are saved, if TB states are not saved, 
in every event, every cycle, or every transaction during the entire simulation period of the 
1®* simulation run (for example VCD dump or FSDB dump, etc) and are translated into a 

30 set of new TBs which use for the post-1®* simulation. If newly generated a set of TBs is 
used instead of an original TB, the compilation time can be increased due to the increase 
of file size for TBs, but the elapsed time for running TBs in the simulation run time is 
reduced as their structure is the form of simple patterns. 

Moreover, the technique mentioned above can use the results of RTL simulation 
35 using a RTL design code efficiently in the debugging for the gate-level simulation in 
which the gate-netlist is synthesized from the RTL code, and if necessary the timing 
information is back-annotated from the placement and routing. More specifically, the 
event-driven simulation or cycle-based simulation is used for the first simulation run, 
which is the front-stage simulation with a RTL design code while saving the design states 
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of the design code at specific simulation times, then for the one or more post-1 
simulation as the back-stage simulation the gate-level simulation is carried out in parallel 
by utilizing those design states of the RTL design code saved at the first simulation. 
Above said gate-level simulation could be the timing simulation using SDF(Standard 
5 Delay Format), or the functional simulation at the gate level without using any timing 
information. As explained earlier, if the 1®* simulation is executed at higher level of 
abstraction than the post-1®^ simulation while saving the dynamic information(for example, 
the minimal design state information of the design objects to be verified and, if necessary 
inputs information included, or the complete design state information of the design 

10 objects to be verified) of one or more design objects in DUV which need visibility, the 
post-1^* simulation as the back-stage simulation is using said dynamic information, and if 
two simulation results of the 1^^ simulation and post-1 simulation are same, then a pair 
of simulation which uses the different level of abstraction for the 1®* simulation and the 
post-1^* simulation (for example, cycle-based simulation at RTL for the 1®* simulation and 

15 event-based simulation at RTL for the post-1®* simulation) can run much faster 
(increasing simulation performance greatly) than a pair of simulation which uses the 
same level of abstraction (for example, event-based simulation at RTL for both the 1®* 
and post-1^* simulations). 

Besides of the simulation performance increase when the two simulation results of 

20 the 1®* simulation and post-1®* simulation are same, there is another important merit when 
two simulation results of the 1®* simulation and post-1®* simulation even are not same. 
The top-down design methodology is widely used in the most of modern designs. In this 
methodology, along to the design creation from the high-level of abstraction to the low- 
level of abstraction the verification should be also carried out through the same path, i.e. 

25 from the high-level of abstraction to the low-level of abstraction (for example, from 
behavioral to RTL, and from RTL to gate-level). As the method mentioned in the present 
invention can allow to use the simulation results at higher level of abstraction to the 
simulation at the lower level of abstraction (for example, using the simulation results at 
behavioral level to the simulation at RTL, the simulation results at RTL to the simulation 

30 at gate level, etc), the design consistency can be systematically and efficiently verified 
during the verification process. Therefore, this simulation method is a new verification 
methodology which can reduce not only the total debugging time, but also the total 
verification and design time. The advantage is similar to one from the Gain-based 
Synthesis (GBS), which is using the physical synthesis, proposed by Magma Design 

35 Automation, Inc. which had been a big success in the design implementation phase. The 
biggest problem in the chip designs is it is highly possible to incur too many iterations in 
the design and verification processes which result from the different results in the later 
stages of design cycles from the predicted one in the earlier stages of design cycles, 
which largely comes from raising the level of design abstraction further for coping with 
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highly complex design problems. But, as both the proposed method in the present 
invention and the GBS method can provide the maximal consistency in the refinement 
process from the high level to the low level of the abstraction, it can commonly prevent 
the excess iterations. As the verification results at the higher level of the design 
5 abstraction is able to be a reference (or a golden), the overall verification and design 
process can be carried out quickly as much as possible. There are many clear 
advantages that the use of the simulation results at the higher level of the design 
abstraction in the simulation at the lower level of the design abstraction by combining 
multiple simulation results at two or more different levels of the abstraction. In the 

10 performance point of view it is mostly desirable to simulate the entire DUV at the higher 
level of the abstraction, but the concept explained above can be still applicable even 
when only one or more specific design objects in DUV are described at the higher level. 
For example, let's assume there are five design blocks 80. 81. 82, 83, and 84 in a DUV. 
and 82, 83, and 84 are written in cycle-based SystemC descriptions, but 80. and 81 in 

15 event-driven Verilog RTL. In this case, as a cycle-based simulation for 82, 83, and 84 is 
co-executed together with an event-driven simulation for BO. and B1, the simulation at 
the higher level of the abstraction is carried out in DUV partially for higher simulation 
speed. In general, the simulation results at the higher level of the abstraction can be 
thought as a special case of modeling process from the lower level of the abstraction. 

20 Therefore, even in this special case, it should be guaranteed that DUV must be operated 
correctly (in other words, to make a design robust the simulation results of two different 
abstraction levels for the front-stage simulation and the back-stage simulation should be 
same). From this fact, the simulation results at the higher level of the abstraction could be 
the role of a very useful reference in most cases. Therefore, two or more two-stage 

25 simulation runs at different abstraction levels and the design debugging method through 
the consistency checking of those simulation results are a new very effective technique 
for the verification. Similarly, it is also possible to use of the simulation results at the 
lower level of the design abstraction in the simulation at the higher level of the design 
abstraction by combining multiple simulation results at two or more different levels of the 

30 abstraction. 

The verification apparatus and verification method previously explained can be 
applicable to the case in which one or more simulation accelerator(s), hardware 
emulator(s), prototyping system(s). formal tools(s) such as model checker(s) or property 
checker(s) is used in addition to simulator(s). More specifically, the 1^' verification run, 
35 which is the front-stage verification, uses one or more simulator(s), simulation 
accelerator(s), hardware emulator(s), prototyping system(s). formal tools(s) such as 
model checker(s) or property checker(s), or any combination of those to save the minimal 
information (for example, the state information of one or more design objects in DUV to 
be verified at one or more verification times, and if necessary, values of all inputs and 
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inouts in input mode of said design objects during the entire verification period) which 
requires to execute at the post-1^* verification runs, which is the back-stage verification, 
with one or more simulator(s), simulation accelerator(s), hardware emulator{s), 
prototyping system(s), formal tools(s) such as model checker(s) or property checker(s), 
5 or any combination of those in either sequential or parallel. 

Moreover, it is possible to quickly get the dynamic information on one or more 
design objects in DUV during a verification run (for example, VCD or FSDB dump in DUV 
and TB during the simulation run) with the two-stage verification runs which consist of the 
front-stage verification run and the back-stage verification runs. The dynamic information 

10 obtained in the verification run Vt can be reused entirely or partially in other verification 
run Vt+j after Vt (for example, the verification run to examine the correctness of a design 
modification) so that Vt+j can be executed even faster. Such debugging process, we'll 
call the rapid execution of a verification run as the incremental verification, which makes 
sure the design bug is actually removed, and there are two cases where the dynamic 

15 information can be reused. 

First, the reuse could be applied in the case of regression testing, which is needed 
whenever there is any design modification during the debugging, and the case of 
assuring the correctness of modification after the design object has been modified. In 
these cases, a verification run is not carried out with the entire design object (including 

20 both DUV and TB). Instead, during one or more specific verification periods (for example, 
from the verification time 0 to tm), one or more design objects which are modified, 
DO(mod) only are executed at faster speed, and during remaining verification times (for 
example, after tm) the entire DUV and TB are executed. The critical element for this 
method is to identify one or more periods in which only one or more design objects, that 

25 are modified, can be executed. This can be done by comparing, in real time, the dynamic 
information of modified design objects after modification with one which has been already 
obtained before modification. Also, it is necessary to choose the modified design 
objects, DO(mod), properly. To obtain the simulation speed-up more in the simulation 
after design modification in simulation-based verification, the boundary of DO(mod), i.e. 

30 the size of DO(mod), should be small. But, because the execution speed of hardware- 
assisted verification platforms is almost independent of the design size, it is not 
necessary to keep the boundary of DO(mod) small if a hardware-assisted verification 
platform(for example, simulation accelerator) is used (For example, in case of simulation 
acceleration, the entire DUV can be selected as DO(mod) even one of lower-hierarchy 

35 design objects inside DUV only is modified. But, in simulation that lower-hierarchy design 
object should be selected as DO(mod)). One example of a specific method is following 
(we'll call this as the checkpoint-based method). It is possible to achieve a verification run 
with both a precision and a high performance if at each verification run in the regression 
test after design modification, comparing all values on the outputs and inouts ports in out 
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mode of modified design objects. Vi(post_o), with all values on same ports of same 
design objects saved before design modification, Vi(pre_o), in real time, only modified 
design objects are executed with the replaying input stimuli or the Input stimuli portion of 
replaying input/output stimuli, previously saved in a specific format (for example, the form 
5 of TB. the VCD format, or the binary format, etc) from the verification run before design 
modification, from the verification time 0 up to the verification time when Vi(post_o) and 
Vi(pre_o) are become different (lefs call this time as tm afterward). Only after tm, the 
whole design objects including both all modified design objects and unmodified design 
objects are simulated together. But, it is absolutely necessary to align two verification 

10 times for the state information of modified design objects and that of unmodified design 
objects at tm. when two compared values become different and all design objects are 
simulated together. One of effective way for doing this is to save the state information of 
design objects one or more time regularly (for example, twenty saving in total) during a 
verification run before design modification, and to use them. One method to save the 

15 dynamic information will be explained in detail below. 

If the verification platform is a simulator, there are two ways. One is to save the 
simulation states one or more times before the design objects are modified, and use 
them later. This is because the simulation state has any design states information 
completely. There are many techniques to save simulation states. To most convenient 

20 one is to use a simulation state saving command (for example, save or checkpoint 
commands in HDL simulators) built in any simulators, or the snapshot for an arbitrary 
program. Second way is to save the design states one or more times before the design 
objects are modified during the verification run (for example, simulation or simulation 
acceleration), and use them later. This method is especially useful when a hardware- 

25 assisted verification platform is used. The reason is any hardware-assisted verification 
platforms do not provide snapshot/restart capability unlike to simulators. 

A preferred embodiment of the present invention will be described below, with 
reference to the accompanying drawings. 

FIG. 1 is an example of the schematic view of the design verification apparatus in 
30 accordance with the present invention. 

FIG. 2 is another example of the schematic view of the design verification 
apparatus in accordance with the present invention. 

FIG. 3 is a schematic view of a simulation process by the method proposed in the 
present invention. 

35 FIG. 4 is a schematic view of a bug finding and removing process throughout the 

simulation proposed in the present invention, which consists of the 1^* simulation as the 
front-stage simulation and the post-1^* simulations as the back-stage simulation. 
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FIG. 5(a) is a schematic view showing a verification process in the verification 
using the apparatus showing in FIG. 1 or FIG. 2. 

FIG. 5(b) is a schematic view showing another verification process in the 
verification using the apparatus showing in FIG. 1 or FIG. 2. 

5 FIG. 6(a) is a schematic view showing a verification process in which the post-1®* 

simulations as the back-stage simulation are executed in parallel, using the verification 
apparatus in FIG. 2. 

FIG. 6(b) is a schematic view showing another verification process, in which the 
post-1®* simulations as the back-stage simulation are executed in parallel, using the 
10 verification apparatus in FIG. 2. 

FIG. 6(c) is a schematic view showing another verification process, in which the 
post-1^* simulations as the back-stage simulation are executed in parallel, using the 
verification apparatus in FIG. 2. 

FIG. 6(d) is a schematic view showing another verification process, in which the 
15 post-1^* simulations as the back-stage simulation are executed in parallel, using the 
verification apparatus in FIG. 2. 

FIG. 7 is another example of the schematic view of the design verification 
apparatus in accordance with the present invention. 

FIG. 8 is an example of the schematic view of the design verification apparatus in 
20 accordance with the present invention which consists of verification software of the 
present invention, at least one computer having at least one simulator, and at least one 
hardware-assisted verification platform. 

FIG. 9 is an example of the schematic view of the design verification apparatus in 
accordance with the present invention which consists of verification software of the 
25 present invention, at least two computers having at least two simulators, at least one 
hardware-assisted verification platform, and a computer network which connects among 
them. 

FIG. 10 is an another example of the schematic view of the design verification 
apparatus in accordance with the present invention which consists of verification software 
30 of the present invention, at least one computer having at least one simulator, and at least 
one hardware-assisted verification platform. 

FIG. 11 is an example of the schematic view showing the reuse of the previous 
verification results in the verification using the apparatus in FIG. 8. 
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FIG. 12 is an example of the schematic view showing the reuse of the previous 
simulation results in the verification using the apparatus in FIG. 1. 

FIG. 13 is an example of the schematic view showing the fast execution of 
verification process by re-using the verification results of any design objects unaltered 
5 on an arbitrary verification platform after some design objects are modified. 

FIG. 14 is an example of the schematic view showing the fast execution of 
verification process by re-using the verification results of any design objects unaltered 
on an arbitrary hardware-assisted verification platform after some design objects are 
modified. 

10 FIG. 15 is an example of the schematic view showing the fast execution of 

simulation process by re-using the simulation results of any design objects unaltered 
on a simulator after some design objects are modified. 

As the present invention may be embodied in several forms without departing from 
the spirit or essential characteristics thereof, it should also be understood that the above- 
15 described embodiments are not limited by any of the details of the foregoing description, 
unless otherwise specified, but rather should be construed broadly within its spirit and 
scope as defined in the appended claims, and therefore all changes and modifications 
that fall within the meets and bounds of the claims, or equivalence of such meets and 
bounds, are therefore intended to be embraced by the appended claims. 
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[Claims] 

[Claim 1 ] A design verification apparatus comprising: 
a verification software and one or more simulators, wherein said verification software 
5 instruments the additional code or circuit to the design code or synthesized net-list in an 
automatic way so that the minimally necessary information, with which one or more pest- 
le* simulation runs as the back-stage simulation can be executed against one or more 
design objects in said design code or synthesized net-list, can be collected during the 1®^ 
simulation run, which is the front-state simulation, and said one or more post-1 
10 simulation runs are executed fast while obtaining the visibility, thereby providing both fast 
simulation speed and high visibility for debugging. 

[Claim 2] A design verification method, in which one or more design bugs in the 
design code or synthesized gate-level net-list are identified and collected by a number of 

15 simulation executions with a number of test benches, comprising; 

some of said simulation executions is decomposed into the 1^^ simulation run as the front- 
state simulation and the post-1®^ simulation runs as the back-stage simulation, verification 
software instruments the additional code or circuit to the design code or synthesized net- 
list in an automatic way so that the minimally necessary information, with which one or 

20 more post-1®* simulation runs as the back-stage simulation can be executed against one 
or more design objects in said design code or synthesized gate-level net-list, can be 
collected during the 1®* simulation run, which is the front-state simulation, and said one or 
more post-1®^ simulation runs are executed fast while obtaining the visibility, thereby 
providing both fast simulation speed and high visibility for debugging. 

25 

. [Claim 3] The design verification apparatus and verification method according to Claim 
1, Claim 2, Claim 12, Claim 54, or Claim 55 wherein said minimally necessary 
information includes to save one or more simulation states into files at some fixed interval 
or, one or more specific simulation times. 

30 

[Claim 4] The design verification apparatus and verification method according to Claim 
1, Claim 2, Claim 12, Claim 54. or Claim 55 wherein the collection of said minimally 
necessary information at the 1®* simulation run as the front-state simulation includes to 
probe on all inputs and inouts in one or more design blocks existed in the design code or 
35 synthesized gate-level net-list during the entire simulation and save them into files, and 
use them as input stimuli at the post-1^* simulation runs which are the back-stage 
simulation. 

[Claim 5] The design verification method according to Claim 3 wherein from said one 
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or more saved simulation states which have stored at 1^^ simulation run as the front-state 
simulation, one simulation state is selected and used so that one of post-1 simulation 
runs can start from the simulation state selected and during the simulation all signals and 
variables in the design or synthesized gat-level net-list are probed. 

5 

[Claim 6] The design verification method according to Claim 5 wherein the post-1®* 
simulation runs are started with a simulator from two or more saved simulation states one 
by one sequentially which have stored at 1^* simulation run as the front-state simulation, 
one simulation state, which is the latest simulation state in the simulation time, is selected 
10 and used so that first of many post-1^* simulation runs can start from the latest simulation 
state selected and during the simulation all signals and variables in the design or 
synthesized gat-level net-list are probed, and more post-1®* simulation runs are also 
executed in the reverse order of simulation state saving times. 

15 [Claim 7] The design verification method according to Claim 1, Claim 2. Claim 3, Claim 
5, Claim 6, Claim 12. Claim 54, or Claim 55 wherein for the simulation state saving 
method at one or more simulation times during the 1^* simulation run, which is the front- 
stage simulation, the save command or checkpoint command of the simulator is used, 
and for the method of starting one or more post-1^* simulation runs which are the back- 

20 stage simulation from one of said saved simulation states, the restart command or 
restore command of the simulator is used. 

[Claim 8] The design verification method according to Claim 4 wherein the collection of 
said minimally necessary information at the 1®* simulation run as the front-state simulation 

25 includes to probe on all inputs and incuts in one or more design blocks existed in the 
design code or synthesized gate-level net-list during the entire simulation and save them 
into files, they are compiled with one or more design blocks existed in the design code or 
synthesized gate-level net-list in a simulator for generating one or more simulation 
execution files, and one of them is executed while additional probing is applied to said 

30 one or more design blocks existed in the design code or synthesized gate-level net-list at 
the post-1®* simulation runs which are the back-stage simulation, thereby providing both 
fast simulation and visibility inside the design blocks. 

[Claim 9] The design verification method according to Claim 1, Claim 2, Claim 3, Claim 
35 5, Claim 6, Claim 12, Claim 54, or Claim 55 wherein each of one or more post-1®* 
simulation runs, which is the back-stage simulation, is transformed into two or more 
partial simulation runs which use two or more simulation states saved during the 1®* 
simulation run, which is the front-stage simulation, and said two or more partial simulation 
runs are executed in parallel by initializing the simulators' each state with each of said 
4 0 saved simulation states and independently running two or more simulators which are 
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installed on two or more connputers connected into a computer network, thereby 
achieving a fast simulation. 

[Claim 10] The design verification method according to Claim 1. Claim 2. Claim 3, 
5 Claim 5, Claim 6, Claim 12. Claim 54. or Claim 55 wherein each of one or more post-1®* 
simulation runs, which is the back-stage simulation, is transformed into two or more 
partial simulation runs which use two or more executable files of a simulator, which is 
obtained by compiling two or more design blocks and their dump files for probing values 
on all inputs of inouts of said two or more design blocks during the entire 1^^ simulation 
10 run, which is the front-stage simulation, and said two or more partial simulation runs are 
executed in parallel by independently running said two or more executable files of a 
simulator with two or more simulators which are installed on two or more computers 
connected into a computer network, thereby achieving a fast simulation. 

15 [Claim 11] The design verification method according to Claim 1, Claim 2. Claim 3, 
Claim 5, Claim 6, Claim 12, Claim 54, or Claim 55 wherein each of one or more post-1®* 
simulation runs, which is the back-stage simulation, is transformed into two or more 
partial simulation runs which use two or more executable files of a simulator, which is 
obtained by compiling two or more design blocks and test benches converted from their 

20 dump files for probing values on all inputs of inouts of said two or more design blocks 
during the entire 1®* simulation run, which is the front-stage simulation, and said two or 
more partial simulation runs are executed in parallel by independently running said two or 
more executable files of a simulator with two or more simulators which are installed on 
two or more computers connected into a computer network, thereby achieving a fast 

25 simulation. 

[Claim 12] A design verification method, in which the additional simulation uses the 
results from previous execution of arbitrary simulation, simulation acceleration, hardware 
emulation, or prototyping comprising, and said additional simulation is decomposed into 

30 the 1®* simulation run as the front-state simulation and the post-1®* simulation runs as the 
back-stage simulation, verification software instruments the additional code or circuit to 
the design code or synthesized net-list in an automatic way so that the minimally 
necessary information, with which one or more post-1®* simulation runs as the back-stage 
simulation can be executed against one or more design objects in said design code or 

35 synthesized gate-level net-list, can be collected during the 1®* simulation run, which is the 
front-state simulation, and said one or more post-1®* simulation runs are executed fast. 

[Claim 13] The design verification method according to Claim 1, Claim 2, Claim 3, 
Claim 4, Claim 5, Claim 9, Claim 10. Claim 11. Claim 12. Claim 23, Claim 24, Claim 25, 
4 0 Claim 27, Claim 54. or Claim 55 wherein the 1®* simulation run, which is the front-stage 
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simulation, is a parallel simulation. 

[Claim 14] The design verification method according to Claim 31. or Claim 32 wherein 
the 1^* simulation run. which is the front-stage simulation, is executed in cycle-based 
5 simulation for entire DUV or one or more design objects in DUV, and one or more post-1 
simulation runs, which is the back-stage simulation, is executed in event-driven 
simulation for entire DUV or one or more design objects in DUV. 

[Claim 15] The design verification method according to Claim 31, or Claim 32 wherein 
10 the 1^^ simulation run, which is the front-stage simulation, is executed with SystemC 
simulator for entire DUV or one or more design objects in DUV, and one or more post-1 
simulation runs, which is the back-stage simulation, is executed with Verilog simulator, 
VHDL simulator, or SystemVerilog simulator for entire DUV or one or more design objects 
in DUV. 

15 

[Claim 16] The design verification method according to Claim 31, or Claim 32 wherein 
the 1^* simulation run, which is the front-stage simulation, is executed in RTL simulation 
for entire DUV or one or more design objects in DUV, and one or more post-1^* simulation 
runs, which is the back-stage simulation, is executed in gate-level simulation for entire 
20 DUV or one or more design objects in DUV. 

[Claim 17] The design verification method according to Claim 14, Claim 15, or Claim 
16 wherein said one or more post-1®* simulation runs are executed in' parallel with two or 
25 more simulators. 

[Claim 18] A design verification method, in which one or more design bugs in the 
design code or synthesized gate-level net-list are identified and corrected by a number of 
simulation executions with a number of test benches, comprising; 

30 some of said simulation executions is decomposed into the 1®* simulation run as the front- 
state simulation and the post-1®* simulation runs as the back-stage simulation, verification 
software instruments the additional code or circuit to the design code or synthesized net- 
list in an automatic way so that the minimally necessary information, with which one or 
more post-1®* simulation runs as the back-stage simulation can be executed against one 

35 or more design objects in said design code or synthesized gate-level net-list, can be 
collected during the 1®* simulation run, which is the front-state simulation, and said one or 
more post-1®* simulation runs are executed fast while obtaining the visibility, thereby 
providing both fast simulation speed and high visibility for debugging. 

4 0 [Claim 19] The design verification method according to Claim 14, or Claim 16 wherein 
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said one or more post-1®^ simulation runs are executed in event-driven simulation at gate- 
level. 

[Claim 20] The design verification method according to Claim 19 wherein said event- 
5 driven simulation at gate-level for said one or more post-1®* simulation runs is timing 
simulation by using timing information extracted from placement and routing. 

[Claim 21] The design verification method according to Claim 14, Claim 15, Claim 19, 
or Claim 20 wherein the state information of one or more design objects in DUV which 
10 require visibility is obtained during the 1^* simulation run, which is the front-stage 
simulation, and one or more post-1^* simulation runs, which is the back-stage simulation, 
is executed by using said state information obtained. 

[Claim 22] The design verification method according to Claim 14, Claim 15, Claim 19, 
15 or Claim 20 wherein the state information of one or more design objects in DUV which 
require visibility is obtained during the 1®* simulation run, which is the front-stage 
simulation, and two or more post-1^* simulation runs, which is the back-stage simulation, 
is executed in parallel by using said state information obtained. 

20 [Claim 23] The design verification method according to Claim 1, Claim 2. Claim 12, 

Claim 54, or Claim 55 wherein the collection of said minimally necessary information at 
the 1®* simulation run as the front-state simulation includes to save the design states of 
one or more design objects in DUV which are required said visibility at regular interval or 
one or more simulation times, and to probe on all inputs and inouts of said one or more 

25 design objects in DUV event by event, cycle by cycle, or transaction by transaction and 
save them into one or more files to use them as input stimuli for the post-1^* simulation 
runs, which is the back-stage simulation, or alternatively to save the test bench states at 
said regular interval or one or more simulation times. 

30 [Claim 24] The design verification method according to Claim 1, Claim 2. Claim 12, 

Claim 54, or Claim 55 wherein the collection of said minimally necessary information at 
the 1^' simulation run as the front-state simulation includes to save the design states of 
one or more design objects in DUV which are required said visibility at regular interval or 
one or more simulation times, and to probe on all inputs and inouts of said one or more 

35 design objects in DUV event by event, cycle by cycle, or transaction by transaction and 
save them into one or more files to use them as input stimuli for the post-1^* simulation 
runs, which is the back-stage simulation. 

[Claim 25] The design verification method according to Claim 23, or Claim 24 wherein 
40 from said one or more saved design states of one or more design objects in DUV and, if 
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necessary, saved test bench states which have stored at one or more simulation times in 
the 1®* simulation run as the front-state simulation, one or more state is selected and 
used so that one or more of the post-1®* simulation runs can start from the design states 
and test bench states selected and during the simulation all signals and variables in the 
5 design or synthesized gat-level net-list are probed. 

[Claim 26] The design verification method according to Claim 25 wherein the post-1 
simulation runs are started with a simulator from two or more saved design states and if 
necessary, test bench states one by one sequentially which have stored at 1^* simulation 
10 run as the front-state simulation, one design state and if necessary test bench state, 
which is the state saved at the latest simulation time, is selected and used so that first of 
many post-1®* simulation runs can start from said state selected and during the simulation 
alt signals and variables in the design or synthesized gat-level net-list are probed, and 
more post-1®* simulation runs are also executed in the reverse order of state saving times. 

15 

[Claim 27] The design verification method according to Claim 1, Claim 2, Claim 23, 
Claim 24, Claim 25, Claim 26, Claim 54, or Claim 55 wherein each of one or more post- 
1^^ simulation runs, which is the back-stage simulation, is transformed into two or more 
partial simulation runs which use two or more design states and, if necessary, test bench 
20 states saved during the 1^* simulation run, which is the front-stage simulation, and said 
two or more partial simulation runs are executed in parallel by initializing the simulators' 
each state with each of said saved states and independently running two or more 
simulators which are installed on two or more computers connected into a computer 
network, thereby achieving a fast simulation. 

25 

[Claim 28] The design verification method according to Claim 1, Claim 2, Claim 3. 
Claim 4, Claim 5, Claim 9, Claim 10, Claim 11, Claim 12, Claim 23, Claim 24, Claim 25, 
Claim 27, Claim 54, or Claim 55 wherein for faster simulation the translated design code, 
which has different syntax from the original code but is functionally equivalent to the 
30 original, is used for the 1®* simulation run. which is the front-stage simulation. 

[Claim 29] A design verification method, in which one or more design bugs in the 
design code or synthesized gate-level net-list are identified and corrected by a number of 
simulation executions with a number of test benches, comprising; 
35 the design states of one or more design objects in DUV and, in necessary, one or more 
test bench states are saved at one or more simulation times, 

[Claim 30] The design verification method according to Claim 21, Claim 22, Claim 23, 
Claim 24. Claim 25. Claim 26, Claim 27, or Claim 29 wherein the minimal design state 
4 0 information of said one or more design objects in DUV which need visibility is used for 
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said design state information of them. 

[Claim 31] The design verification method according to Claim 1. Claim 2. Claim 3, 
Claim 4. Claim 5, Claim 9, Claim 10, Claim 11. Claim 12. Claim 23. Claim 24. Claim 25, 
5 Claim 27, Claim 54, or Claim 55 wherein in the 1®^ simulation run, which is the front-stage 
simulation, at least one or more design objects has design code abstracted more than 
those in the post-1 simulation runs, which is the back-stage simulation, said 1®^ 
simulation is executed at the higher level of abstraction than said post-1 simulation, 
thereby achieving more rapid verification. 

10 

[Claim 32] The design verification method according to Claim 31 wherein the state 
information of one or more design objects in DUV which require visibility is obtained 
during the 1^' simulation run, which is the front-stage simulation, and one or more post-1®* 
simulation runs, which is the back-stage simulation, is executed in parallel with two or 
15 more simulators or in sequence with a single simulator by using said state information 
obtained. 

[Claim 33] The design verification method according to Claim 23, or Claim 24 wherein 
from said one or more saved design states of one or more design objects in DUV which 
20 have stored at 1^* simulation run as the front-state simulation, one design state is 
selected and used so that one of post-1®* simulation runs can start from the design state 
selected and during the simulation all signals and variables in the design or synthesized 
gat-level net-list are probed. 

25 [Claim 34] The design verification method according to Claim 33 wherein the post-1®* 

simulation runs are started with a simulator from two or more saved design states of one 
or more design objects in DUV one by one sequentially which have stored at 1®* 
simulation run as the front-state simulation, one design state, which is the state saved at 
the latest simulation time, is selected and used so that first of many post-1®* simulation 

30 runs can start from the latest design state selected and during the simulation all signals 
and variables in the design or synthesized gat-level net-list are probed, and more post-1®* 
simulation runs are also executed in the reverse order of design state saving times. 

[Claim 35] The design verification method according to Claim 1, Claim 2, Claim 23. 

35 Claim 24, Claim 33, Claim 34, Claim 54, or Claim 55 wherein each of one or more post- 
1®* simulation runs, which is the back-stage simulation, is transformed into two or more 
partial simulation runs which use two or more design states of one or more design 
objects in DUV saved during the 1®* simulation run, which is the front-stage simulation, 
and said two or more partial simulation runs are executed in parallel by initializing the 

4 0 simulators' each state with each of said saved states and independently running two or 
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more simulators which are installed on two or more computers connected into a 
computer network, thereby achieving a fast simulation. 

[Claim 36] A design verification method, in which one or more design bugs in the 
5 design code or synthesized gate-level net-list are identified and corrected by a number of 
simulation executions with a number of test benches, comprising; 

some of said simulation executions is decomposed into the 1^* simulation run as the front- 
state simulation and the post-1^* simulation runs as the back-stage simulation, verification 
software instruments the additional code or circuit to the design code or synthesized net- 

10 list in an automatic way so that the minimally necessary information, with which one or 
more post-1^* simulation runs as the back-stage simulation can be executed against one 
or more design objects in said design code or synthesized gate-level net-list, can be 
collected during the 1®* simulation run, which is the front-state simulation, and said one or 
more post-1®* simulation runs are executed fast while obtaining the visibility, thereby 

15 providing both fast simulation speed and high visibility for debugging. 

[Claim 37] The design verification method, in which a simulation at the lower level of 
abstraction is executed rapidly by using the simulation result at the higher level of 
abstraction. 

20 

[Claim 38] The design verification method according to Claim 37, Claim 57, or Claim 
58 wherein said simulation result at the higher level of abstraction contains the state 
information of one or more design objects. 

25 [Claim 39] The design verification method according to Claim 38, Claim 64, or Claim 

65 wherein state information of one or more design objects is the complete state 
information. 

[Claim 40] The design verification method according to Claim 38, Claim 64, or Claim 
30 65 wherein state information of one or more design objects is the minimal state 
information. 

[Claim 41] The design verification method according to Claim 38, Claim 39, Claim 40, 
Claim 64, or Claim 65 wherein said fast simulation method at the lower level of 
35 abstraction is to use two or more simulation in parallel by using said state information of 
one or more design objects. 

[Claim 42] The design verification method according to Claim 41, or Claim 67 wherein 
said parallel simulation is temporally parallelized one. 

40 
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[Claim 43] The design verification method according to Claim 41. or Claim 67 wherein 
said parallel simulation is spatially parallelized one. 

[Claim 44] The design verification and correction method according to Claim 37 
5 wherein assuming one of two simulation results at the higher level of abstraction and the 
lower level of abstraction as a reference, comparing the simulation result of the lower 
level of abstraction and the simulation result of the higher level of abstraction, finding the 
differences between the simulation result of the lower level of abstraction and the 
simulation result of the higher level of abstraction and making them correct, thereby said 
10 two simulation results compatible. 

[Claim 45] The design verification and correction method according to Claim 44, or 
Claim 59 wherein said simulation at the higher level of abstraction is cycle-based 
simulation, and said simulation at the lower level of abstraction is event-driven simulation. 

15 

[Claim 46] The design verification and correction method according to Claim 44, or 
Claim 59 wherein said simulation at the higher level of abstraction is SystemC simulation, 
and said simulation at the lower level of abstraction is RTL simulation. 

20 [Claim 47] The design verification and correction method according to Claim 44, or 

Claim 59 wherein said simulation at the higher level of abstraction is RTL simulation, and 
said simulation at the lower level of abstraction is gate-level simulation. 

[Claim 48] The design verification and correction method according to Claim 47, 
25 wherein said gate-level simulation at the lower level of abstraction is timing simulation 
using the timing information. 

[Claim 49] The design verification and correction method according to Claim 44, or 
Claim 59, to find situations where two simulation results at the lower level of abstraction 
30 and the higher level of abstraction, the simulation result at the higher level of abstraction 
is used at the simulation at the lower level of abstraction. 

[Claim 50] The design verification and correction method according to Claim 44, or 
Claim 59, to find situations where two simulation results at the lower level of abstraction 
35 and the higher level of abstraction, the simulation result at the higher level of abstraction 
is used at the parallel simulation at the lower level of abstraction. 

[Claim 51] The design verification and correction method according to Claim 49, or 
Claim 50, to find situations where two simulation results at the lower level of abstraction 
40 and the higher level of abstraction, the simulation result at the higher level of abstraction. 
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which is used at the simulation at the lower level of abstraction, contains the state 
information of one or more design objects. 

[Claim 52] The design verification and correction method according to Claim 51, 
5 wherein state information of one or more design objects is the complete state information. 

[Claim 53] The design verification and correction method according to Claim 51, 
wherein state information of one or more design objects Is the minimal state information. 

10 [Claim 54] A design verification apparatus comprising: 

a verification software and one or more simulators, wherein said verification software 
instruments the additional code or circuit to the design code or synthesized net-list in an 
automatic way so that the minimally necessary information, with which one or more post- 
1®^ simulation runs as the back-stage simulation can be executed against one or more 

15 design objects in said design code or synthesized net-list, can be collected during the 1^^ 
simulation run, which is the front-state simulation, and said one or more post-1 
simulation runs are executed fast while obtaining the visibility, thereby providing both fast 
simulation speed and high visibility for debugging. 

20 [Claim 55] A design verification method, in which one or more design bugs in the 

design code or synthesized gate-level net-list are identified and collected by a number of 
simulation executions with a number of test benches, comprising; 

some of said simulation executions is decomposed into the 1^^ simulation run as the front- 
state simulation and the post-1 simulation runs as the back-stage simulation, verification 

25 software instruments the additional code or circuit to the design code or synthesized net- 
list in an automatic way so that the minimally necessary information, with which one or 
more post-1^* simulation runs as the back-stage simulation can be executed against one 
or more design objects in said design code or synthesized gate-level net-list, can be 
collected during the 1^* simulation run, which is the front-state simulation, and said one or 

30 more post-1®* simulation runs are executed fast while obtaining the visibility, thereby 
providing both fast simulation speed and high visibility for debugging. 

[Claim 56] The design verification nriethod, in which there is no change in the design 
objects, the minimal simulation results are saved during a run of the front-stage 
35 simulation, the saved simulation results are used for running one or more back-stage 
simulation either in parallel with two or more simulators or in sequence with a single 
simulator, and if necessary the dump on one or more variables or signals in one or more 
design objects is carried out during the back-stage simulation, thereby achieving high 
visibility. 

40 
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[Claim 57] The design verification method according to Claim 37, said simulation result 
at the higher level of abstraction contains one or more simulation waveform files, and 
those waveform files are used in simulation at the lower level of abstraction. 

5 [Claim 58] The design verification method according to Claim 37, as said simulation 
result at the higher level of abstraction one or more simulation waveform files exist, and 
those waveform files are used in simulation at the lower level of abstraction. 

[Claim 59] The design verification and correction method according to Claim 37 
10 wherein assuming one of two simulation results at the higher level of abstraction and the 
lower level of abstraction as a reference, comparing the simulation result of the lower 
level of abstraction and the simulation result of the higher level of abstraction, finding the 
differences between the simulation result of the lower level of abstraction and the 
simulation result of the higher level of abstraction and making them correct, thereby said 
15 two simulation results compatible. 

[Claim 60] The design verification and correction method according to Claim 44, or 
Claim 59 wherein comparing the simulation result of the lower level of abstraction and the 
simulation result of the higher level of abstraction at one or more specific simulation times, 
20 finding the differences between the simulation result of the lower level of abstraction and 
the simulation result of the higher level of abstraction and making them correct by 
changing the simulation results of the lower level of abstraction to be compatible with the 
simulation results of the higher level of abstraction. 

25 [Claim 61] The design verification and correction method according to Claim 44, or 

Claim 59 wherein comparing the simulation result of the lower level of abstraction and the 
simulation result of the higher level of abstraction at one or more specific simulation times, 
finding the differences between the simulation result of the lower level of abstraction and 
the simulation result of the higher level of abstraction and making them correct by 

30 changing the simulation results of the higher level of abstraction to be compatible with the 
simulation results of the lower level of abstraction. 

[Claim 62] The design verification and correction method according to Claim 44, or 
Claim 59 wherein said simulation at the higher level of abstraction is transaction-based 
35 simulation, and said simulation at the lower level of abstraction is cycle-based simulation. 

[Claim 63] The design verification and correction method according to Claim 44, or 
Claim 59 wherein said simulation at the higher level of abstraction is behavioral level 
simulation, and said simulation at the lower level of abstraction is register transfer level 
40 simulation. 
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[Claim 64] The design verification method according to Claim 37, Claim 57, or Claim 
58 wherein said simulation results at the higher level of abstraction contains the design 
state information of one or more design objects and the information of all inputs and 
5 inouts in input mode of said one or more design objects during the entire simulation 
period. 

[Claim 65] The design verification method according to Claim 38, or Claim 64 wherein 
said design state information of one or more design objects is not one for the entire 
10 simulation period, but one at one or more specific simulation times in the simulation 
period. 

[Claim 66] The design verification method according to Claim 37, Claim 57, or Claim 
58 wherein said simulation results at the higher level of abstraction contains the 
15 information of all inputs and inouts in input mode of said one or more design objects 
during the entire simulation period. 

[Claim 67] The design verification method according to Claim 66 wherein two or more 
simulation runs at the lower level of abstraction are executed in parallel by using said 
20 information of all inputs and inouts in input mode of said one or more design objects 
during the entire simulation period so that the simulation at the lower level of abstraction 
are executed fast. 

[Claim 68] The design verification method according to Claim 41 , or Claim 67 wherein 
25 said parallel execution uses both temporally parallel execution and spatially parallel 
execution. 

[Claim 69] The design verification method according to Claim 37. Claim 38, and Claim 
64 wherein two or more simulation runs at the lower level of abstraction are executed in 
30 parallel by using both said design state information and said information of all inputs and 
inouts in input mode of said one or more design objects during the entire simulation 
period so that the simulation at the lower level of abstraction are executed fast. 

[Claim 70] The design verification and correction method according to Claim 44, or 
35 Claim 59 wherein said simulation at the higher level of abstraction is transaction-based 
simulation, and said simulation at the lower level of abstraction is event-driven simulation. 

[Claim 71] The design verification and correction method according to Claim 44, or 
Claim 59 wherein said simulation at the higher level of abstraction uses both transaction- 
40 based simulation and cycle-based simulation together, and said simulation at the lower 
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level of abstraction is event-driven simulation. 

[Claim 72] The design verification method according to Claim 28 wherein at least part 
of said translated design code, which has different syntax from the original code but is 
5 functionally equivalent to the original, is obtained by logic synthesis or logic 
transformation. 

[Claim 73] The design verification method according to Claim 28 wherein at least part 
of said translated design code, which has different syntax from the original code but is 
10 functionally equivalent to the original, is represented by binary decision diagram, or multi- 
valued decision diagram, and simulated. 

[Claim 74] The design verification method, in which a simulation at the higher level of 
abstraction is executed such a way that its simulation result is entirely or partially 
15 corrected by using the simulation result at the lower level of abstraction. 

[Claim 75] The design verification and correction method according to Claim 37, or 
Claim 74 wherein comparing the simulation result of the lower level of abstraction and the 
simulation result of the higher level of abstraction, finding the differences between the 
20 simulation result of the lower level of abstraction and the simulation result of the higher 
level of abstraction and making them correct by conducting one or more partial simulation 
where they are different, thereby said two simulation results compatible. 

[Claim 76] The design verification method according to Claim 75 wherein in said one 
25 or more partial simulation the simulation at the lower level of abstraction uses the 
simulation result of the higher level of abstraction, the simulation at the higher level of 
abstraction uses the simulation result of the lower level of abstraction just obtained, and 
these processes are repeated until said two simulation results compatible. 

30 [Claim 77] The design verification and correction method according to Claim 44. or 

Claim 59 wherein said simulation at the higher level of abstraction is gate-level simulation 
without timing information, and said simulation at the lower level of abstraction is gate- 
level timing simulation using timing simulation. 

35 [Claim 78] The design verification method according to Claim 47, or Claim 77 wherein 

if said gate-level simulation is not timing simulation, then at least part of design objects is 
represented by binary decision diagram, or multi-valued decision diagram, and simulated. 

[Claim 79] The design verification method according to Claim 76 wherein simulation 
4 0 period is narrowed down as said repeated processes, in which the simulation at the lower 
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level of abstraction uses the simulation result of the higher level of abstraction, the 
simulation at the higher level of abstraction uses the simulation result of the lower level of 
abstraction just obtained, and so on, go on until said two simulation results compatible. 

5 [Claim 80] A design verification apparatus comprising: 

a verification software and at least two or more different verification platforms, wherein 
said verification software instruments the additional code or circuit to the design code or 
synthesized net-list in an automatic way so that the minimally necessary information, with 
which one or more post-1 verification runs as the back-stage verification on the 
10 verification platforms among which at least one verification platform is different from the 
verification platform for the 1^^ verification run can be executed against one or more 
design objects in said design code or synthesized net-list, can be collected during the 1^^ 
verification run, which is the front-stage verification, and said one or more post-1®^ 
verification runs are executed fast. 

15 

[Claim 81] A design verification apparatus according to Claim 80 wherein said 
verification software and said at least two or more different verification platforms, wherein 
said verification software instruments the additional code or circuit to the design code or 
synthesized net-list in an automatic way so that the minimally necessary information, with 

20 which one or more post-1®* verification runs as the back-stage verification on the 
verification platforms among which at least one verification platform is different from the 
verification platform for the 1®* verification run can be executed against one or more 
design objects in said design code or synthesized net-list, can be collected during the 1®* 
verification run, which is the front-stage verification, and said one or more post-1®* 

25 verification runs can be executed fast as most of those runs can be started at other 
simulation times than the simulation time 0. 

[Claim 82] A design verification apparatus according to Claim 80 wherein said 
verification software instruments the additional code or circuit to the design code or 

30 synthesized net-list in an automatic way so that the minimally necessary information, with 
which one or more post-1®* verification runs as the back-stage verification on the 
verification platforms among which at least one verification platform is different from the 
verification platform for the 1®* verification run can be executed against one or more 
design objects in said design code or synthesized net-list, can be collected during the 1®* 

35 verification run, which is the front-stage verification, and said one or more post-1®* 
verification runs can be executed fast as they are only executed against one or more 
specific blocks, not for all blocks. 

[Claim 83] A design verification method, in which one or more design bugs in the 
4 0 design code or synthesized gate-level net-list are identified and corrected by running a 
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number of verification executions using at least two or more verification platforms in 
hybrid way, comprising; 

some of said verification executions is decomposed into the 1®^ verification run as the 
front-stage verification and the post-1^* verification runs as the back-stage verification, 
5 the additional code or circuit is instrumented to the design code or synthesized net-list in 
an automatic way so that the minimally necessary information, with which one or more 
post-1®* verification runs as the back-stage verification on the verification platforms 
among which at least one verification platform is different from the verification platform for 
the 1®* verification run can be executed against one or more design objects in said design 
10 code or synthesized gate-level net-list, can be collected during the 1®* simulation run. 
which is the front-stage simulation, and said one or more post-1®* simulation runs are 
executed fast as they are executed against one or more specific blocks only. 

[Claim 84] A design verification method, in which one or more design bugs in the 
15 design code or synthesized gate-level net-list are identified and corrected by running a 
number of verification executions using at least two or more verification platforms in 
hybrid way, comprising; 

some of said verification executions is decomposed into the 1®* verification run as the 
front-stage verification and the post-1®* verification runs as the back-stage verification, 

20 the additional code or circuit is instrumented to the design code or synthesized net-list in 
an automatic way so that the minimally necessary information, with which one or more 
post-1®* verification runs as the back-stage verification on the verification platforms 
among which at least one verification platform is different from the verification platform for 
the 1®* verification run can be executed against one or more design objects in said design 

25 code or synthesized gate-level net-list, can be collected during the 1®* simulation run, 
which is the front-stage simulation, and said one or more post-1®* simulation runs are 
executed fast as most of those runs can be started at other simulation times than the 
simulation time 0. 

30 . [Claim 85] A design verification method according to Claim 83, or Claim 84 wherein 
said one or more post-1®* verification runs as the back-stage verification on the 
verification platforms among which at least one verification platform is different from the 
verification platform for the 1®* verification run are executed in parallel on at least two or 
more verification platforms. 

35 

[Claim 86] A design verification method according to Claim 85 wherein said one or 
more post-1^* verification runs as the back-stage verification on the verification platforms 
among which at least one verification platform is different from the verification platform for 
the 1®* verification run are executed in parallel on at least two or more verification 
4 0 platforms, and these at least two or more verification platforms are different platforms. 
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[Claim 87] A design verification method according to Claim 83, or Claim 84 wherein 
said one or more post-1^* verification runs as the back-stage verification on the 
verification platform which is different from the verification platform for the 1^* verification 
5 run is sequentially executed. 

[Claim 88] The design verification method according to Claim 83, Claim 84, Claim 85. 
Claim 86, or Claim 87 wherein the post-1^* verification runs are started with a verification 
platform from two or more saved design states one by one sequentially which have 

10 stored at 1^* verification run as the front-stage verification, one design state, which is the 
latest design state in the verification time, is selected and used so that first of many post- 
1®^ verification runs can start from the latest design state selected and during the 
verification all signals and variables in the design or synthesized gat-level net-list are 
probed, and more post-1®* verification runs are also executed in the reverse order of 

15 design state saving times. 

[Claim 89] The design verification method according to Claim 80, Claim 81. Claim 82, 
Claim 83, or Claim 84 wherein the collection of said minimally necessary information at 
the 1®* verification run as the front-stage verification includes to save design states of 
20 DUV at some fixed interval, or one or more specific verification times, and the values on 
all inputs and inouts of DUV in the entire verification run period into file. 

[Claim 90] The design verification method according to Claim 80, Claim 81, Claim 82, 
Claim 83, or Claim 84 wherein the collection of said minimally necessary information at 
25 the 1^* verification run as the front-stage verification includes to save design states of 
DUV and the states of TB at some fixed interval, or one or more specific verification times 
into file. 

[Claim 91] The design verification method according to Claim 80. Claim 81, Claim 82, 
30 Claim 83, or Claim 84 wherein the collection of said minimally necessary information at 
the 1®* verification run as the front-stage verification includes to save simulation states at 
some fixed interval, or one or more specific verification times into file if the 1®* verification 
run is carried out with at least one or more simulators. 

35 [Claim 92] The design verification method according to Claim 91 wherein said one or 

more saved simulation states as the collection of said minimally necessary information at 
the 1^* simulation run as the front-stage verification is done by using the save command 
of simulators, and the post-1®* verification runs start from the design states which are 
extract from said one or more saved simulation states. 

40 
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[Claim 93] The design verification method according to Claim 80, Claim 81 . Claim 82, 
Claim 83, or Claim 84 wherein the collection of said minimally necessary information at 
the 1^^ verification run as the front-stage verification includes to prove and save the 
values on all inputs and inouts of specific design blocks existed in the design code or 
5 synthesized design net-list during the entire verification run period into file. 

[Claim 94] The design verification method according to Claim 85, or Claim 86 wherein 
each of one or more post-1 verification runs, which is the back-stage verification, is 
transformed into two or more verification sub-runs which use two or more DUV design 
10 states saved during the 1®* verification run. which is the front-stage verification, and said 
two or more verification sub-runs are independently running in parallel on two or more 
verification platforms which are installed on two or more computers connected into a 
computer network, and merging the verification results on said two or more verification 
platforms together as the entire verification result, thereby achieving a fast verification. 

15 

[Claim 95] The design verification method according to Claim 85, or Claim 86 wherein 
each of one or more post-1^* verification runs, which is the back-stage verification, is 
transformed into two or more verification sub-runs which use two or more simulation 
executable files compiled from the files of design blocks in DUV and their input and input 

20 values probed and saved during the 1®^ verification run, which is the front-stage 
verification, and said two or more verification sub-runs are independently running in 
parallel on two or more verification platforms which are installed on two or more 
computers connected into a computer network, and merging the verification results on 
said two or more verification platforms together as the entire verification result, thereby 

25 achieving a fast verification. 

[Claim 96] A design verification apparatus according to Claim 82, wherein said one or 
more post-1®* verification runs as the back-stage verification on the verification platforms 
which is different from the verification platform for the 1®* verification run can be executed 
30 against one or more design objects in said design code or synthesized net-list, can be 
collected during the 1®* verification run, which is the front-stage verification, and said one 
or more post-1®* verification runs can be executed fast as they are only executed against 
one or more specific blocks, not for all blocks. 

35 [Claim 97] The design verification method according to Claim 83 wherein the collection 

of said minimally necessary information at the 1®* verificationn run as the front-stage 
verification includes to probe on all inputs and inouts in one or more design blocks 
existed in the design code or synthesized gate-level net-list during the entire verification 
and save them into files, they are compiled with one or more design blocks existed in the 

4 0 design code or synthesized gate-level net-list in a verification platform for generating one 
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or more verification execution files, and one of them is executed while additional probing 
is applied to said one or more design blocks existed in the design code or synthesized 
gate-level net-list at the post-1®* verification runs which are the back-stage verification, 
thereby providing both fast verification and visibility inside the design blocks. 

5 

[Claim 98] A design verification method, in which the additional verification uses the 
results from previous execution of arbitrary simulation, simulation acceleration, hardware 
emulation, or prototyping comprising, and said additional verification is decomposed into 
the 1^* verification run as the front-stage verification and the post-1 verification runs as 

10 the back-stage verification, verification software instruments the additional code or circuit 
to the design code or synthesized net-list in an automatic way so that the minimally 
necessary information, with which one or more post-1®* verification runs as the back- 
stage verification can be executed against one or more design objects in said design 
code or synthesized gate-level net-list, can be collected during the 1®* verification run, 

15 which is the front-stage verification, and said one or more post-1®* verification runs are 
executed fast. 

[Claim 99] A design verification apparatus comprising: 
a verification software and at least one or more verification platforms, wherein said 
20 verification software instruments the additional code or circuit to the design code or 
synthesized net-list in an automatic way so that the dynamic information can be collected 
during one or more verification runs, and said dynamic information collected is re-used at 
the post-debugging simulation after at least one design object is changed for debugging, 
thereby total verification time can be entirely or partially reduced. 

25 

[Claim 100] A design verification method comprising: 
by using a verification software and at least one or more verification platforms the 
additional code or circuit is instrumented to the design code or synthesized net-list in an 
automatic way so that the dynamic information can be cpllected during one or more 
30 verification runs, and said dynamic information collected is re-used at the post-debugging 
simulation after at least one design object is changed for debugging, thereby total 
verification time can be entirely or partially reduced. 

[Claim 101] A design verification method according to Claim 99, or Claim 100 wherein 
35 the detection method of finding verification time when the verification result of at least 
one design object changed for debugging is not same as the verification result of the said 
design object before the change is to compare all values of outputs and inouts of said 
design object before and after the change in automatic way. 

4 0 [Claim 102] A design verification method according to Claim 99, or Claim 100 wherein 
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the detection method of finding verification time when the verificafion result of at least 
one design object changed for debugging is not same as the verification result of the said 
design object before the change is to compare all values of outputs of said design object 
before and after the change in automatic way. 

5 

[Claim 103] A design verification method according to Claim 99. or Claim 100 wherein 
the detection method of finding verification time when the verification result of at least 
one design object changed for debugging is not same as the verification result of the said 
design object before the change is to apply the re-simulation input stimuli, which Is 
10 obtained in one or more verification runs before modification, to said changed design 
object in automatic way. 

[Claim 104] A design verification method according to Claim 99. Claim 100, Claim 
101, Claim 102. or Claim 103 wherein the verification run after at least one design 
15 objects is modified is executed only with said at least one design object changed for 
debugging and its re-execufion input stimuli at least to the first verification fime when the 
verification result of at least one design object changed for debugging is not same as the 
verification result of the said design object before the change from the verificafion fime 0. 

20 [Claim 105] A design verificafion method according to Claim 99, Claim 100, Claim 

101, Claim 102, or Claim 103 wherein the verification run after at least one design 
objects is modified is executed only with said at least one design object changed for 
debugging, its re-execufion input stimuli, and the part of design objects unchanged at 
least to the first verification time when the verification result of at least one design object 

25 changed for debugging is not same as the verification result of the said design object 
before the change from the verification time 0. 

[Claim 106] A design verification method according to Claim 99. Claim 100. Claim 
101. Claim 102, or Claim 103 wherein the verification run after at least one design 
30 objects is modified is executed with all design objects after first verification time of 
different results when the verification result of at least one design object changed for 
debugging is not same as the verification result of the said design object before the 
change in automatic way. 

35 [Claim 107] A design verification method according to Claim 99, Claim 100, Claim 

101, Claim 102, or Claim 103 wherein the verification run after at least one design 
objects is modified is executed with all design objects from the verification time of 
different results when the verification result of at least one design object changed for 
debugging is not same as the verification result of the said design object before the 

4 0 change to the verification time of different results in automatic way. 
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[Claim 108] A design verification method according to Claim 99, Claim 100. Claim 
101, Claim 102, or Claim 103 wherein the verification run after at least one design 
objects is modified is executed only with said at least one design object changed for 
5 debugging and its re-execution input stimuli at least to the first verification time of 
different results when the verification result of at least one design object changed for 
debugging is not same as the verification result of the said design object before the 
change from the verification time 0, and after the first verification time of different results, 
and the verification run is automatically switched to the verification execution with all 
10 design. 

[Claim 109] A design verification method according to Claim 106. or Claim 108 
wherein to automatically switch the verification run with all of design objects from said 
first verification time for different results, the restoring design states for the design objects 
15 unchanged is occurred with the design state information saved during the verification 
runs before the modification for debugging at the boundary of said first verification time 
for different results. 

[Claim 110] A design verification method according to Claim 109 wherein said 
20 restoring design objects is by re-start capability of simulators, and design states saving is 
by snapshot capability of simulators. 

[Claim 111] A design verification method according to Claim 110 wherein for said re- 
start capability of simulators the restore or restart command is used, and for said 
25 snapshot capability the save or checkpoint command is used. 

[Claim 112] A design verification method according to Claim 99, or Claim 100 wherein 
the detection method of finding verification time when the verification result of at least 
one design object changed for debugging is not same as the verification result of the said 
30 design object before the change is to sequentially compare all values of outputs and 
inouts of said design object before and after the change in automatic way. 

[Claim 113] A design verification method according to Claim 99, or Claim 100 wherein 
the detection method of finding verification time when the verification result of at least 
35 one design object changed for debugging is not same as the verification result of the said 
design object before the change is to compare all values of outputs and inouts of said 
design object in parallel before and after the change in automatic way. 

[Claim 114] A design verification apparatus according to Claim 99 wherein said 
4 0 verification platforms are simulators, simulation accelerators, emulators, prototyping 



39 



PCT/KR05/ 



systems, or their combination. 

[Claim 115] A design verification apparatus according to Claim 99, Claim 100, Claim 
101. Claim 102. Claim 103, Claim 104, Claim 105, Claim 110, or Claim 111 wherein if 
5 said verification run are done entirely or partially, then two or more processes are co- 
executed by inter-process communication for an entire verification run. 

[Claim 116] A design verification method according to Claim 115 wherein at least one 
process among said one or more processes which are co-executed by inter-process 
10 communication collects dynamic information of one or more design objects during the 
verification runs before the design code modification by using snapshot, and the 
verification runs at the specific verification times after the design code modification are 
carried out by re-startability using said dynamic information collected, thereby reducing 
the verification time entirely or partially. 

15 

[Claim 117] A desigh verification method according to Claim 116 wherein for said 
snapshot the save or snapshot capability in simulators is used, and for said re-startability 
the restart or restore capability in simulators is used. 

20 [Claim 118] A design verification method according to Claim 99, Claim 100, Claim 101, 

Claim 102, Claim 103, Claim 104, Claim 105, Claim 106, Claim 108, Claim 109, Claim 
115, Claim 116, or Claim 117 wherein the verification platform contains either the 
simulation accelerator or the verification platforms containing the simulation accelerator. 

25 [Claim 119] A design verification method according to Claim 106, Claim 108, Claim 

109, Claim 110, or Claim 111 wherein said switching time during the verification run after 
design code modification is determined by the instrumented code, which is added to the 
design object, during the verification run in automatic way. 

30 [Claim 120] A design verification method according to Claim 106, Claim 108, Claim 
109, Claim 110, or Claim 111 wherein said alignment of the dynamic information of 
design objects unmodified and modified at said switching time during the verification run 
after design code modification is determined by the instrumented code, which is added to 
the design object, during the verification run in automatic way. 

35 

[Claim 121] A design verification method according to Claim 106, Claim 108, Claim 
109, Claim 110, or Claim 111 wherein said verification run with all design objects after 
said switching time after design code modification is determined by the instrumented 
code, which is added to the design object, during the verification run in automatic way. 

40 
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[Abstract] 
[Abstract] 

The present invention relates to a simulation-based verification apparatus and a 
verification method, which enhance the simulation performance and efficiency greatly, for 
verifying a digital system containing at least million gates. Also, the present invention 
relates to a simulation-based verification apparatus and a verification method used 
together with formal verification, simulation acceleration, hardware emulation, and 
prototyping to achieve the high verification performance and efficiency for verifying a 
digital system containing at least million gates. 
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